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SYSTEM AND- METHOD FOR COMMUNICATION WITH j A 
REMOTE NETWORK DEVICE 

Description 



i 

Technical 



Field 



5 This invention relates to the field of 

communication between digital devices such as computers 
and computer related peripherals across a general purpos 

network. j 

. i 

Background Art 

■ , HIM ;l | | 

10 The need , for digital computers to communicate 

! ' : ■ , t 

to each other and to remotely located computer 
peripherals has long been felt. Numerous technologies 
_ have been diesigned to meet this need, including the use 
of modems for establishing long distance links over the 

15 analog phone network and the creation of networking 

technologies which allow computers and peripherals to 
communicate over a data transmission medium. 

Modems are used in pairs to establish 
communication between two computers, with each modem 

20 being attached to the serial port of its local computer 
as well as connected to the analog telephone network. 
The serial port is a standard interface port on the 
.computer which allows the computer to pass a serial bit 
stream of information to a peripheral such a modem or a 

25 printer. On UNIX based computers and other multi-user 
computer systems, this same serial port is used for 
communication with the terminals which allow users to 
interact with the computer. As a result, it is a 
relatively simple matter to utilize a modem to allow a 

3 0 . remotely located terminal - to communicate with a multi- 
user computer system over the phone lines. 

Because modern multi-user computers are capabl 
of supporting numerous simultaneous users, it is 
desirable to have a number of serial ports through which 

35 terminals can communicate with the computer. 
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* Unfortunately, mounting all of the serial ports directly 
onto the computer can be logistically difficult, .since - 
multi-user computers can often support more than fifty 
terminal connections. As a result, multiplexors have 
5 been utilized to combined serial traffic from numerous, 
internally referenced serial ports into a single 
communication channel. In this way, only one - 
communication cable needs to be attached to the computer. 
On the other end of the communication cable is another 

10 multiplexing device, which separates the combined data 
traffic into data for individual serial ports, and then 
provides the serial ports through which this data can be 
accessed. This type of multiplexing device, called a 
ports concentrator, can be used to provide multiple 

15 serial ports for terminals in a location remote from the 
computer. It is even possible to use multiplexing in a 
system which allows the data on the main communication 
cable to be transported across phone lines using modems. 
This allows multiple serial ports to be accessible at 

20 great distances from the computer. 

Networking technology can also be utilized to 
allow remote communication between a computer and another 
computer or peripheral . Networks which connect computers 
and peripherals within a relatively small area are 

25 referred to as Local Area Networks, or LANs . A general 
purpose network is a communication system utilizing 
standard hardware and standard communication protocols, 
and operating in a mult i -vendor environment. General 
purpose network hardware includes LAN technologies like 

30 Ethernet and Token Ring. Standard Network protocols 
include TCP/IP and SPX/IPX. 

LANs are generally formed by connecting 
computers and peripherals together through a transmission 
medium, and then communicating over the medium by 

35 following standardized communication protocols. These 
protocols set forth such requirements as to how data 
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should be formatted and how data is designated for a 
particular device. Data cannot be sent over the network 
without conforming . to these protocols . 



Application programs 



on a host operating system 
generally depend strongly onj tfce Application Program 
Interfaces (API) for local communication devices provided 
by the host ! operating system;. jThis is especially' 
important on systems like UNIX, whose traditional user 
interface is terminal command line operation. 

General purpose networks most often support two 

\ 

types of communication, a connectionless unreliable 

datagram service ^.nd a reliable bi-d-irectional bytesteam 

connection. ^ The API to both of these services is very 

| ! i 

different from the, serial port API, and in general 

programs written to run on serial devices (known as TTYs) 

■ I IT j | 

require an adaptation layer to jrun correctly. 

In the T-|NiX environment this is generally done 

with the network protocols Telnet anjja Rlogin using a 

virtual TTY device,, known as a pseudo-tty or PTTY device. 

II ! i 1 : f| 

PTTY devices are software entities, not hardware 

| V''| \ : } 

entities, that emulate UNIX TTYs well enough that most 



command line programs will run 



with it hem. 



It is important to distinguish these PTTYs from 
genuine TTYs associated with arid controlling actual 



serial port 
master side 
emulation device. 



hardware 

v I 

The 



A PTTY has a 'slave side and a 



slave side of the [PTTY is the TTY 
and is used fc>y programs that reouire 



the serial port API 



to function. 



Thjje master side: 



interfaces to a network program, such as Telnet or 
30 " Rlogin, that can send data across the network. 1 



The slave 



change user 
expansion 



side of the PTTY; accepts .requests to 



options 

i 1 , 

and other functions 



like line editing characters,! tab 
done !by the line 

However it 



discipline of the j^local operating system 
ignores requests to 



change baud rate*, character size, 
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action on received errors and BI&AK signals, and l:he 
like.- j ■ 

The ! master side of the* PTTY accepts reads,. 



writes , and. a ■ very 
(ioctls) to change 

between the slave aind master devices 

; j ; 

the master side of 'the PTTY appears as 

* ■ ' 
data on the slave side of the PITY, as 

received on a (serial port, and! i-'s processed as input 

i 5 ! - I 

serial data by the line discipline of the operating 

system. The data dhen appears 1 as received data when read 



limited setj of input output controls 
the way data' is passed back and forth 

Data written to 
received serial 
though it had been 



ij . i , 

from the slave side of the PTTYi* Data 



slave PTTY is likewise processed as serial output data by 
the UNIX line j discipline, after which it can be read on 



written to the 



15 the master side. 



1 Ioctl opierations made tfco the 

PTTY are invisible to the master! side, 
possible for the program accessing the 



PTTY to detect that 



slave side of the 
hence it is not 
master side of the 



these calls 1 .'have been made. The 



interface is just -not rich enough to support any 
operations that cannot be done* ib the; line discipline of 



the local operating 
! It should 



system. 

aiso be noteb that 



in most 



implementations, there is not a J «bne-to i one correspondence 
between physical devices and PTTYs . When a connection is 
made into a UNIX system by Telnet or Rlogin, these i 

program simply allocate the next' available PTTY for the 

i . i . j 

session. Hence from 1 session to! session a network user is 

i i . 

likely to get [different PTTY devices, m no obvious 
pattern. This 'makesl it difficult* or impossible to enforce 
system security or user options based on pseudo-tty 
devices. To overcome this to some extent, ad-hoc 
programs are commonly written by terminal server vendors 
that can be attached to the master side of a particular ~ 
PTTY, so that the slave* side of **that PTTY remains ^ 
attached to that program and is*not periodically 



\ 
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reallocated po another use. Such programs can be used 
' f or ji in coming connects and running login- programs „ but are 
i most often used tq j simulate dial -out modems, printers, or 
direct connect serial devices. 1 This use expands [the PTTY 
5i to ojther uses than tTelnet and Rlogin, but because of 

their limited emulation of a genuine TTY device, sthey 

I I ' '^'i \ ' ' ! 1 

require varied workarounds andi cause continual , 

I maintenance and compatibility problems. 

I Telnet also uses TCP/IP flow control for port 

10 data! flow controls .and sends commands in sequence with the 

[ ! I h J ! I ! 1 1 < 

data so that commands cannot be processed until the data 

« ahead of th!em in .the data stream have also been 

i i • if i] 



processed. 



As, a result, Telnet requires the use jof the 



expedited data feature of TCP/IP to i send certain [commands 

f I I :| * • i f- i! , . ; . 

such as user requested interrupts. j T h e implementation of 

this requires that i data ahead of the user interrupt be 

I ^ i i '■ l ■ ; r ■ T i 

discarded before .the interrupt can be processed. 1 
j Unfortunately, this procedure can place a 

; tremendous [strain on the host computer as well as the 

\ ! f f ' 1 ! . *■ i ! I 

network itself. R6r instance, when typing on a remote 

terminal connected f through thej network, each keystroke is 

processed, jsent dyer the network to j the host computer, 

. and then echoed b^qk over the netwojrk to the remote 

terminal. On an [Ethernet network, a transmitted j 

r t . s ! ! . . I 

. character must be ^transmitted pn a 64 byte minimum size 
i! message packet and | the acknowledge also requires ja 64 
t| byte* messagre packet. Thus, twp 64-|>yte packets must be 

, transmitted for each character^ typed. ' 

! - I ; ■ vi : ■ S 

r , In addition, the receiving of the character by 

-i the host computer j { Requires a task switch to run the PTTY 

"control software to receive the character, and a task 

1 I - ' i ■ * I ■ " ! -. 

•i -switch back to the f PTTY control software to transmit the 



echo character . 



35- 



Devices called terminal servers make remote 
logins, utilizing the TELNET and RLOGIN commands, 
available to users through a serial port without 
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- requiring the users to be logged onto a . computer on the 
network. A user connected to;a serial port on the - 
terminal server can use RLOGIN or TELNET to connect to a 
multi-user computer on the network. A second user on the 
5 terminal server could also connect to the same multi-user 
computer, and thereby establish a second communications 
link with its own PTTY assigned to it. Connection made 
by the terminal server through TELNET, RLOGIN and similar 
procedures of course embody the same disadvantages as f 
10 connection made using those procedures through a - / 

different computer on the network. J 

Summary of the Invention 
The present invention comprises a communication 
system which overcomes the disadvantages of the prior art 

15 by allowing a host computer full access to the 

asynchronous ports located on a remote terminal server 
across a general purpose network. By utilizing a unique 
device driver interface and multiplexing communication 
protocol, the server is able to communicate data and 

20 control commands for multiple ports on a single 

connection, thereby reducing demands on the network. In 
addition, the present invention provides genuine TTY 
devices across the network which have all the 
characteristics of local communication ports. The 

25 present invention also makes possible access to the ports 
on the server to multiple host computers located on the 
network, allowing fair access to shared resources such as 
modems and printers. Finally, the invention can also be 
implemented in hardware, further increasing compatibility 

30 with existing host computer software and further reducing 
host computer overhead. 

The present invention operates over the 
reliable communication link provided by a general purpose" 
network between a client (usually a host computer) .who 

35 wishes >o access or provide access to remote 
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15 



20 



25 



one-to-one 



communication ports and a server that incorporates such 
ports, '< * » 

The present invention differs from traditional 
PTTY implementations, in that it provides genuine TTY 
devices across a general purpose network. Unlike the PTTY 
implementations, the .TTYs of the current invention have a 
correspondence with actual hardware, and allow 
the host operating system to control that hardware as if 
the serial Iports were. directly 1 connected to the host 
operating system arid dedicated] to this use. 

Where it does not , interfere with the 

. ' ' . I I 

assumptions^ made by application programs, the current 

invention then loosens these restrictions, and extends 

the f unctionality^tof these ports to f allow sharing with 

other hosts on the. network, f an <p with dynamic port 1 i 

allocation with PBX-style hunt j groups . The present 

invention allows each operating system to maintain a 

one-to-one 



correspondence with 
allow ittlose . TTYs jto 



genuine TTYs, but can 
be accessed for other 



optionally 

purposes wh'eii theyj |are ' not currently in use by the 

current opejrating^system. I i i 
I i * • t * ! ! \ 

Each' client that wishes to use one or more 

ports on th!e: server opens a single connection to that 

lzing ithe protocol provided by the present 



server util 
invention ( 



the. "Communication Protocol") 

1 ■ t "I '! 



All 



communication between the client anc| server which uses 

the Cpmmunication^rotocol then proceeds using this 

single connectionl;»,;no matter how many ports are used by 

i " r : i i . 

Additional connections ^between the client 



the client, 



30 and server may be opened under 



as Telnet and Rlogin, however the existence of these 



I 

prior art p'rotoco:! 1 connections 



under the control of the present invention' s 

I i 

Communication Protocol . When the connection between the 



35 -~ client and 



server 



prior art protocols such 



does 



not affect the ports 



is broken ifor any 



reason", all the ports 



i 
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- Imder Communication Protocol control are closed, ^and all 
resources claimed by that client are returned-. 
I The] existence of a Communication Protocol, 

connection does not: automat icalQJy grant the client access 
5 to all port resources on the server. Before the client 
accesses a port, the client must first 1 successfully OPEN _ 
the port, after which time the; 'client is granted 

exclusive access to the port uht'il thei client CLOSES the 

! j i ■ I - 

port. < 

' il i 1 . ■ 

10 Once a port is opened, u the client may send 

requests to change baud rate, control modem settings, and 

the like. The client may send | data out the port, and the 

server automatically sends thei client all data received 
! , •. i • . , 

±n the port. .Under the Communication Protocol, the 

15 client may request status updates from the server. The. 
updates can be made' immediately 'upon request, or the * 
client may request the server inform the client of any 
changes to various status conditions (such as modem input 
signals) as they change. : 
: .ii 

'J \ ; ! 

20 Brief Description of the Drawings 

1 ■ if 1 ! I 

Figure l illustrates al general purpose computer 
networking linking a variety of * host computers and a 
server of the present invention! I 1 J 

1 Figure 2 illustrates at* client computer attached 

j j 
25 across a general purpose network to a' server of the 

present invention, 'including the critical components of 

the server. fc • ! I 

i I ' 1 

Figure 3 illustrates ' a wrap-around sequence 

space with a single sequence number pointing toward a 

3 0 location in the sequence space. 

Figure 4 illustrates a. wrap-around sequence 

space with two sequence numbers' pointing toward locations" 

in the sequence space . * < 



WO 95/25311 



PCT/US95/03183 



- 9 



Figure 5 illustrates, the process by which a 
: server controls the flow of data transmitted from a 
r client through a server to a port . [ 

Figure 6 illustrates the process by which a 
5 '. client controls the flow of data transmitted from a 
client through a server to a port, j | 

Fjigure Trillustrates! the process by which a 
server controls the flow of data transmitted from a port 
through a server to a client, j * 
10 figure 8. illustrates! a client computer attached 

across a general purpose network tola server of the 
present indention} 1 j including the critical components of 



the client 



driver , 

- I » 

Detailed Disclosure' of the Invention 



15 | fig. I 1 ishows a general pu:ppose network 10 

interconnecting aiAfariety of computers including a UNIX 
i computer "12 ,\ a Digital 1 Equipment Corporation's VAX 

computer 1^ and a* 'Novell Netwo[rk of,PCs at a particular 
■ location 16 . The* network 10 c|an utilize any of a variety 
20 of standard networking communication protocols, such as 
TCP/IP, SPX/IPX and X*25, as Ipng as the protocol 
.provides for error free byte stream data transmission, 
i The communication,, protocol operates | on a specific logical 
topology such as Ethernet or Token Ring. j 
25 i - ~ A tvpicai network connecting the computers and 

networks shpwn in^FIG. 1 would utilize the TCP/IP 
protocol rxinning pn top of Ethernet*. The TCP portion of 
the protocol takes j byte streani data] and converts' it to 



/packets." '['he IP portion takes the packets' and forms 
30 datagrams, while ^Ethernet takes thej ( datagrams and/forms 
frames. This typical configuration'; will be utilized for 
the purpose of explaining the present invention, although 
- the invention itself is independent of the network 
protocol utilized. 
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A server 20 of the present invention operates 
to connect various ports (not7Shown) to the network 10.- 
Communication lines 22 can be connected to the ports on 
the server 20. Although only five communication lines 22 
5 are shown in FIG. l, the server 20 typically has sixteen 
or more ports which can be connected to the network 10. 

FIG. 2 shows the primary elemients of the 
communication between one or more clients 18 and the 
server 20 across a general purpose network 10. The 

10 client 18 can be a host computer such as a UNIX computer 
12 or a VAX computer 14, or even a local area network 16. 
The server 20 is connected to the network 10 through the 
server's network interface 30. The network interface 3 0 
provides the industry standard hardware. and software 

15 control necessary for the server 20 to communicate over 

the network 10 in the same way as any other device on - the 
network 10. As with all industry standard network 
interfaces, the network interface 30 is capable of 
receiving data frames from the network 10, determining 

20 whether the data is addressed to server 20, and, if so, 

make the data available in a byte stream form by removing 
the network formatting and reassembling the frames, 
datagrams and packets. In other words, the network 
interface 30 of the present invention contains the 

25 functionality of the Transport, Network, Link and 
Physical layers of the International Standards 
Organization Open Systems Interconnection (ISO/OSI) 
model . 

The byte stream data provided by the network 
30 interface 30 is then supplied to a central processing 
unit (CPU) 32, which coordinates the implementation of 
the Communication Protocol of the present invention. The 
program modules necessary for implementation of the 
Communication Protocol are stored in the program memory ~~ 
35 portion 36 of the server memory 34. 
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After the CPU 32 has analyzed the data received 
from the network (interface 3 0,j raw ^ata- is passed through 
to the appropriates port 40 on server 20. The ports 40 on 
the server 12 0 may | be asynchronous, synchronous or 
parallel ports, ^ttached to the ports 40 may be a 
devices^ such as terminals, printers or 



variety of 
modems . 



Data th^it is sent frpm th^p client 18 for 
transmission through the portsj 40 is stored in an output 
10 or transmit! buffeijr 42 until thje por£ 40 is ready to 

transmit tlie' data*.,, Data that is sent into the server 20 
through the ports, 4 0 is handled similarly. The data 

I i ' ' i ! i ' 

coming from port 40 for transmission to the client 18 is 
stored in ilnput or receive bufjfer 44 until it is ready to 
15 be transmitted ov t er the network 10 to the client 18. The 

I 1 i n:! , ; ( \ J 

Communication Protocol of the present invention is 



executed by the C3JU 32 and the 



step|of formatting the 

ames , datagrams and 



byte stream transmission, into the fir. 

M \ ! I I T 

packets required cjri the network! 10 j.s handled by , the 

network interface 3 0. , i ■ , , 

The server memory : 34 j also j contains server state 

variables 38 , whijcli contain the i status , informatipnj , 

necessary to f ulljj i implement the Coinmunication Protocol - 



The types of, server state variables 
preferred embodiment of the t present 
in -Table l.l ' 



These variable types 



data structures, 



and are used 



the workings of the server 20 



38 stored in jthe 
invention are shown 



represent a variety of 
in vajrious ways to J control 
and to facilitate . . 



and the server, 20, 



communication between the client 18 

j f; ? i | 

the purpose of these variables, they are 



To clarify 

.discussed below in] detail. 



i 



The Client Connections list maintains a list of 

f * ! ! I i ' ' ' ' 

that currently have a connection with the 

"'?'! • ■ i ■ . i 

server 20 open under the Communication Protocol. ;In the 



clients 18 
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preferred embodiment, the server 20 can support eight -or 
more - simultaneous client connections.' 

The Message Build Interval controls the polling 



interval to determine how often' the server 20 internally 
polls its state to determine wii'ether information needs to 

- I" . ■ I i - 

be constructed according to the Communication Protocol 
and transmitted to !the client IB 1 . In the preferreld 
embodiment, this polling takes place approximately fifty 
times per second, jThis results in a worst case dellay 
time of twenty milliseconds, with an average of tdn 
milliseconds.' This is adequate* 'for users at terminals, 
and for most sliding window protocols'. 

! i . I i 

i By transmitting information only at the message 

' I ! i I 

build interval, the server 20 is able to accumulate 



15 information during 



the intervals Thus', data is sent in 

j 



larger packets than if data were! sent a character at a 



time, which limits jthe demands I on both 
the client 18_i "«« ■ 1 . 

I The I Port Open State variable 



the network 10 and 



is a data 



structure which tracks which clients 18 have a connection 

1 U I 

open to a port 40, land which clients 18 are waiting to 

* ( ■ 1 I 

open that port 4 0. I In other words, for each open port 40 

this data structure tracks which 1 client 18 currently 

i ( 

holds the port 40 and which clients 18 . are on the Open 
wait list. Further details on opening! a port 40 are set 
forth below. ' I 

The i Port 'Baud Rate variable stores the baud 
rate of each port 40 in such a way that the baud rate of 
the port 40 is 1,843,200 divided 1 by the Port Baud Rate 
variable. This representation requires only sixteen bits 
to represent all standard baud iriates in the range 50- 
115K Baud. < 

■ The Processing Flags variables control, 

character size, hardware state,- and input/output - 
character processing for each port 40. There are four 
sets of processing flags that are stored in the server 
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state variables: CFLAGS, I FLAGS , OFLAGS AND XFLAGS. 

I 

CFLAGS, I FLAGS and OFLAGS are standard flags provided by 

I l* 1 ^ - " f 

in the termio interface of most standard UNIX operating 
systems, and are used m the present; invention as. is 



standard in 
Termio ) . 



M 

the industry. (Unix Prolgrammers Manual, 



CFLAGS has settings which control UART hardware 

settings on ! the port 40, including character size, stop 

j I'tf I i 

bits, and parity. \ The actual CFLAGS settings that it 

P> , i \ I 

10 makes sense to implement in the server 20 include CBAUD, 

;CSIZE, CSTOPB, CREAD, PARENB, PARODD', and HUPCL. : 

Similarly, IFLAGS settings ;which| control the 

processing of data at the server 20 received from the 

; I !' t . 1 ! t 

port 40. IFLAGS settings include control over the 



15 mterpretat 



on of [Break conditions, error handling and 



software flow control settings.) The, IFLAGS implemented 

on the server 20 are IGNBRK , IGNPAR , j PARMRK , INPCK, 

ISTRIP, IXON, IXOFF, IXANY, DOSMODE . \ OFLAGS controls the 

| - 't • \\ ■ 

server 20 processing of data ; intendep to be outputted 

over the ports 40 j OFLAGS settlings Control such things 

as CR and NL settings and tab delay, |j and are defined by 

termio to include OPOST, OLCUC,! ONLCR, OCRNL, ONOCR, 

I 'i <. 

ONLRET, OFILL, OFDEL, NLDLY, CRDLY, TABDLY, BSDLY, VTDLY, 

FFDLY. I | :! 

j- | j | f 

i ~ In the preferred embodiment, various flags 

i I - • •* i . | t 

settings which are no longer used with modern 

| W I [ ft ! 

communications equipment are not supported. These flags 

settings include OFILL, OFDEL ,-;NLDLy[, CRDLY, BSDLY, VTDLY 

and FFDLY, all from OFLAGS. Each of, these settings could 

1 • .! 1 8 : 

be supported with only slight njodif iqations to the 

preferred embodiment, but the decision whether or not to 



ill 



support these setting is irrelevant to the present 



invention. 



XFLAGS is ! a set of flags taken from t'exmfo 
LFLAGS, plus. some additional functions. The XFLAGS 
settings- are set forth in Table 2. 
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The XFLAGS -variables (except for XCASE which is 
a UNIX line, discipline or LFLAG variable) are _ extensions, 
to the UNIX feature set either to expand the interface to 
multiple host operating systems or to provide value-added 
5 features. These XFLAGS settings interact with the 

settings of the CFLAGS, I FLAGS and 0 FLAGS settings. "The 
details of the interactions are as follows. 

If the XPAR setting of XFLAGS is reset or if 
the underlying hardware does not support mark/space 
10 parity, then the PARODD setting of CFLAGS selects odd 

parity if set and even parity if reset. Otherwise PARODD 
selects space parity if set and mark parity if reset. 

If PARMRK of I FLAGS and XMODEM of XFLAGS are 
set, any change in one or more modem signals is encoded 
15 in the input stream as FF 80 MM, where MM is the updated 
modem signal value. 

If XCASE of XFLAGS is set, certain non- 
alphabetic printing characters are converted to two- 
character equivalents on output according to UNIX 
20 specifications . 

XTOSS of XFLAGS controls whether a character 
that resumes output during flowing control is ignored or 
not. When IXANY of I FLAGS is reset, output is restarted 
only when a matching XON or XXON character is received. 
25 However, when IXANY of I FLAGS is set, any received 

character resumes output. Thus, if XTOSS is set, the 
character that resumes output is discarded. If XTOSS is 
reset, any non-flow control character resuming output is 
placed in the data stream. 
30 When XIXON of XFLAGS is set, an extra set of 

output flow control characters is enabled. Receipt of 
XXOFF stops output while XXON resumes it. 

The Flow Control Characters variables determine 
what the flow, control characters will be. Two sets of - ~" 
35 output flow control characters are supported and one set 
of input flow control characters is supported. In 
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addition, a flow control escape character is supported to 
allow input J of flow control characters without 
interpretation. The Flow Control Characters include l) 
the standard sof tv^re flow control start character], (XON) , 
5 2)s the standard software flow control stop character 
(XOFF) , 3) the extra software flow control start 
character (XXON) , ^4) the extra software flow contrcpl stop 
character (XXOFF) ^and 5) the flLow Control Escape 
Character (LNEXT) 1 ; , 

After reppipt of the j LNEXTjj character, the next 
character receive^ '|Ls not recognized as a flow control 
! character, and bot^hj characters j are pjlaced into the input 
! data stream' !■ i ,'j • • j 

1 I i ! I 

t- Returning- to the Server State Variables 38, the 



10 



20 



35 



15 jprovision of full !|mpdem contjrol facilities to the client 



18 are provided through eight Modem 



Control variables . 



Each of these variables use masks to represent the 

I : ' f 
operating state of f ra. modem. 



The seven modem variables 



I 

of modem signals, 
Table 4 



r 



are s,et forth as fidllows in Talple 3 



All variables shown in Table 3 represent ( sets 



using the bi£ assignments shownj in 



The usejijdf the different Modem Control 



I variables are as follows, 



The 



25 j Variable" contains j^the values of RTS jand DTR last j ( 

• requested by the client 18* Tliese values are changed by 



issuing a rjequest 



MOUT Modem Control 1 



When the RTS /DTR 



,ito the server 20. 

bits |in MFLpW are) 

MOUT are temporarily ignored, and ttiose signals indicate 



:s t et, the corresponding values siet in 



30 - whether the 



server, ;I20 is ready to receive data, f When 



jreceive is pausedpufthese signajLs ar^s driven low. When 
j receive* is restartaejd, tj:he signals aap driven high, 
! MFLOW is 'used to inhibit the "in-band" output 

of data. Data, commands, and responses that are handled 
" sequence as the normal flow of- data in, and 



in the same 
out of data 



portS|j r i|s called in-band ; l data. Data, 
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.commands, and Responses that a±*e' I transmitted ahead of ' 
iiormal data , and arje processed - immediately upon receipt , 
are called outj-of-band data. in I band output is inhibited 
when any of CTS/DSR/DCD/RI are Wt in MFLOW and at least 
one of the corresponding hardware input! signals is low. 

Flow 1 control characters and ! transmit immediate 
characters arej not governed by software flow control or 
MFLOW. They are transmitted according to the 
CTS/DSR/DCD/Rlj f lowj control constraints given by MCTRL. 
The server 20 automatically resets any bit in MCTRL that, 
is not set in MFLOWI j ! ' 

MSTAT contains the current state of the input 
and output modem signals. H* 1 

MLAST contains the last modem status reported 

to the client 18. i 1 
ii j " , 

MTRAN contains the modem signals that have - 

changed since they Were last reported Jo the client 18. 

It is possiblejj f or MSTAT to equai MLASt| and still have 

bits set in MTRAN. This cohditidn indicates that some 

signals in MSTAT made at least one transition, and then 

returned to the value last repotted to the client 18 1 " 

When j any of the six mod'em signals are set I in 
MINT, corresponding 'changes in tkbse mokem signals are 
reported to the client 18. f I 

The server 20 of the present invention 
maintains per- port statistical counters) in the server 
state variables 38 do keep track of the! number of receive 
character errors occurring on that port' 40. These 
counters are referred to as the Line Error Counters. A 
different counter is 1 utilized to | J track each of the 
following counts: the number of li^RT overrun errors, the 
number of buffer ove'rflow errors r the number of framing 
errors, the number of parity errors and ' the . number of 
breaks received. Each of these variables "are i6-bit 
wrap-around counters . that keep track of the number of 
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line errors that have occurred in each category for that 
port 40. . ; _ 

An additional Line Error Counter variable 
tracks the report 1 time in milliseconds. If this variable 

. .! ; i L 

is zero, line errors are not automatically reported to 
the client 18. Otherwise trie server 20 inspects 'the 

1 11 it. i i 

counters at each specified interval,! and sends a .complete 

tk -h\ It' i 

report to the client 18 if a!ny • have 'changed since the 



last report . j 

10 The Send Break and Send Immediate variables 

| h i i j 

allow a client 18 to request the server 20 to immediately 

send either a Break or another ; character to a port 40 . 

* ! !i ( I > I t 

The Send Immediate variable is [a one character buffer 

I ■'.». : [ t 

tins the character that the client 18 wishes to 

-i i }•* I 1 l I 

15 send. The Send Break variable \ contains the length in 



_which conta 



milliseconds! of the requested break J Two special' cases 



exist in thej contents of the Send Break variables. When 

' I i Hit I | f jj 1 

an FFFF value is sent to Send Break/ this denotes an 

i " - ' ! i i' i 

infinite break time. A 0000 sent to Send Break cancels 

! .11 ,v 1 i t ; i : 

20 any break in I progress. Any other value sent to the 

server 20 i's! simply added to Send Break time, and the 

break proceeds for the combined duration of the two 

requests ' 

Since the current invention does not utilize 

I j '}■* : ! i 

25 TCP/IP flow, control for port flow control, data received 

. ! i - M - I I 

by .the client 18 or server 20 can always be immediately- 
processed. I As a result, it is easy 
- ' | ! f - i , , t 

commands and data' without disrupting, the flow of in -band 

M J 

data. i "I . 

30 - The server 20 also maintains a list of status 

-conditions 'in the Server State Variables 38. These 
- status conditions, are stored in the jEvent Reporting 

variables, and represent conditions that are of general 

interest to! -the client 18. The client 18 can poll these, 
35 or request that the server 20 automatically send the 

appropriate event information whenever the conditions 



to send out -of -band 
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change. The Event Reporting variables allow the server 
20 to track the sending of this event inf ormation : . Table 

5 sets forth the various Event Reporting variables. 

EINT can be set by the client 18 to create a 
5 predetermined condition which will cause event 

information to be sent by the server 20 to the, client 18. 
Event information is sent to the client 18 whenever 
{ETRAN & EINT) is non-zero. 

Note that it is possible for ESTAT to equal 
10 ELAST and still have bits set in ETRAN. This condition 

indicates that some conditions in ESTAT made at least one 
transition, and then returned to their ELAST values 
before they could be reported to the client 18. 

The events that are recorded in these variables 
15 are set forth in Table 6, along with the masks which show 
how the events are indicated. The events listed in Table 

6 are communication events well understood in the context 
of this invention. 

The last two types of variables stored in the 
20 server state variables 3 8 are the Input Sequence and 
Receive Buffer Parameters variables and the related 
Output Sequence and Transmit Buffer Parameters. These 
variables represent the state of the transmit buffers 42 
and the receive buffers 44 which are associated with each 
25 port 40. 

To communicate the flow of data in the buffers 
42, 44, the preferred embodiment of the server 20 uses 
sixteen bit wrap-around sequence numbers. Two sequence 
numbers are associated with each buffer 42, 44. The 

30 first sequence number communicates the sequence number of 
the next byte to be placed into the buffer. This first 
sequence number is labeled RIN for the receive buffer 44 
and TIN for the transmit buffer 42. The second sequence 
number communicates the sequence number of the next byte~- 

35 to be removed from the buffer. This second sequence 

number is labeled ROUT for the receive buffer 44 and TOUT - 
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20 



25 



30 



for the transmit puffer 42. These sequence numbers begin 
at . zero and advance by one for each byte of data 
transmitted or received. When) the sequence numbers reach 
FFFF, they wrap back to zero and continue when the next 



byte of data. is transmitted or 
noted that the TIN-,' TOUT, RIN, 



received. 



It should be 



and ROUT variables are 



sequence numlper variables used) to communicate between the 
client 18 and the^server 20. They do not specify the 
physical positions of data in the transmit and receive 
buffers 42 , j 44, wl^ich is done through techniques well 
known in the' art and not described lierein. 

These s^cjuence numbers, aijid the other variables 
which make up the j| Input Sequence and Receive Buffer t 
Parameters and the Output Sequence and Transmit Buffer 
Parameters ^ariable^ types are shown Jin Tables 7 and 8. 

Wrap-around sequence ; numbers like TIN, TOUT, 



RIN and ROUT j have 
properties 



I! 



pme jvery helpful ^mathematical 



numbers can be confusing, 



and subtraction, since 



However , sequence 
especially when doing addition 

j ! '■■ ; I 

special definitions of these functions must be used as a 

result of their wrap-around nature. , 

To clarify their usej an example embodiment of 
I I j f 

a transmit buffer 42 will be discussed, as illustrated in 

FIGs. 3 and| 4. In, the embodiment o^j FIG. 3, the TOUT 



sequence" pointer ^pointing to j:he next byte of data to be 
transmitted] out of 1( | the buffer 42' to ja port 40 and 



represented in FIGj., 3 by arrow 



50) is set to byte S. 



When n bytes 'of data are transmitted, the transmitted 
bytes are numbered S though S | (n 4; 1). By convention, 
we say the buffer^has transmitted bytes between S and (S 



n)_. However, since we are adding 



a sequence number that wraps at OxFF'FF, we must compute 



the express 



ion S * jt n using the 



an ordinary number to 



following formula: 



ti j. i (S + n) & OxFFFF 



WO 95/25311 



PCIYUS95/03183 



10 



15 



20 



20 



with & indicating a logical AND "operation. Thus, -where S 
is 0xFFF8 and'n is the formula for' "computing S i n 
give us OxFFFC. Similarly, where! S is 0xFFF8 and n is 9, 



S + n is 2. 



After transmitting n &ytes, the TOUT sequence 

pointer must £e advanced to the v new location pf -the next 

byte to be transmitted. This is 1 ' done Toy replaeinq the 

J. J - I 

old value of TOUT with the computed" result S + n. 

To determine the number of bytes that exist 
jj ? I ! 

between two sequence number, subtraction is used. 

However, a special rule must be used tcb determine the 

result of the 'subtraction of one! sequence number from 

^ i • ' i 

another. Thus, to determine the' number of bytes between 

sequence number si and s2, the following formula is used: 

i?i - ■ 1 



(s2 



SI) 



& Oxffff 



This formiila works even if sequence si is 

numerically greater than sequence number s2 . For r 

1 I I 

example, if si = OxFFFO and s2 = J 3, then (s2 - si) & 



correct answer. 



OxFFFF is 0x13, the] 

In ^act t ie concept of 11 distance between 
sequence numbers is so important , that it is useful to 



define it as: 



DIST(from, to) = (((to) - (from)) & Oxffff) 

Given a pair of sequetrice numbers si and s2, it 
I I 1 i t 1 I 

25 is true that s,3 is the sequence location of a byte 

between si and s2 only if: ' 1 \ 



DIST(sl, S3) < DIST(Sl, S2) 



This- formula can be read as: "s3 is between si 
and s2 if and only if the distance from si to s3 is= less 
30 than the distance from si to s2. n - ' 
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Sequence numbers can communicate the amount of 
data, or the amount of free space in a remote buffer. 
Assume that in the transmit buffer 42 for a particular 
port 40, as shown in FIG. 4, the TOUT sequence number 50 
is set to si, while the TIN sequence number 52, 

f " ; r i 

representing the next byte to be transmitted through the 
port 40, is set to S2 . In FIG 4, both TOUT and TIN are 
represented by arrows pointing to locations in transmit 
buffer 42. It is possible to determine that the number 
of bytes in the transmit buffer 42 fjor that port is: 



v ,1 



[ DIST(sl, S2) 



In, addition, if the transmit buffer 42 for that 



port is of fixed s^ize SIZE, it | is cl 



ear that the number 



of free bytes in the buffer is: 



15 



SIZE -- DIST(sl, s2) 



Both the .client 18 and the server 20 of the 
I i * i | 1 . . 

present invention make use of the special characteristics 

of the wrap!- around sequence numbers .to control the in- 

band flow of information between th^m. Both client 18 

20 and server 20 send jin-band data to the other only, when 



30 



This 



pre -authorization is 



pre -authorized to^do so. 

acoomplisheid, by communicating the ariiount of data that the 
otixer is allowed tJ transmit t6 it. ? When the sender has 



sent enough 



data jtp E fill this space ,j| the sender pauses in 



25 transmission until the receiver removes some of the data 



and informs 
"available. 



the sender that additional space is 



- To control the flow from client 18 to server 

I ' i 1 ' "I ! ! 

20, the serjver 20 provides the client 18 with the size of 
its transmit buffer 42, and the sequence of the first 
byte currently in the transmit ■ buffer 42 (TOUT) . The 
client 18 keeps track of- the data that has previously 
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been sent to the server 20 by keeping its own client 18 
send sequence number. By using this send sequence, 
number, along with the information provided by the server 
20, the client 18 can compute the amount empty space left 
5 in the server's transmit buffer 42. The client 18 

therefore will not send any more data than will -fit in 
that empty space . 

This process is shown in detail by the flow 
chart of FIG. 5. The indication to start transmitting 

10 activity is shown in box 100 on the chart. The first 

step is to determine whether data has been received from 
the client 18 through the network, interface 30 of the 
server 20. If so, as indicated in box 102, it is 
necessary to receive the data and place the data into the 

15 transmit buffer 42 for the appropriate port 40. Whenever 
data is placed in the transmit buffer 42 , TIN is 
incremented, as is shown in box 104. 

Whether or not data was received from the 
client 18, it is possible that data exists in the 

20 transmit buffer 42 that can be sent out through the port 
40, as shown at query box 106. If data does exist, the 
data in the buffer 42 should be sent out over the port 
40, box 108, and TOUT should be incremented, box 110. 

At this point, the server 2 0 must determine 

25 whether it is necessary to report TOUT to the client 18. 
Three tests, indicated by query boxes 112, 114 and 116, 
are utilized in the preferred embodiment. The first test 
112 compares TOUT, which indicates the next output byte 
to be transmitted, with TPOS . TPOS is one of the Output 

30 Sequence and Transmit Buffer Parameter variable stored in 
the server state variables 38. TPOS indicates the last 
value of TOUT that was reported to the client 18. If the 
difference between TOUT and TMAX, computed using the 
sequence number subtraction formula" described above, is 

35 greater that TMAX, the TOUT will be reported. TMAX. is 

also stored in the server state variables 38, and is set 
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20 



35- 



by the client 18 ( to determine the transmission intervals 
at which TOUT will be reported. Note that whenever TOUT 
is reported to the client 18, at bo^ 120, TPOS is ( then 
set to the value pf TOUT at box 122 : 

The second test for reporting TOUT, at Box 114, 
determines whether ; the data was in the buffer 42 at least 

" tl5; [ T 

TTIME milliseconds ago, and since that time TOUT has not 



been reportjed, with TTIME being a server state variable 

If so, TOUT will 

be reported to client 18. i I 

Thje final test, 116, compares the value of TOUT 



38 which can 1 be set by the client 18 



with the value of TREQ i 
server state ! variables 



TREQ, J stored as one of the 
38, is set by the client 18 so 



that when TOUT parses TREQ, TOUT is ^reported to the 



15 client 18. 



Mathematically, tot compare the wrap-around 



sequence number T^UT with TREQ, it is necessary to test 
their relatjibnshipj ! by comparing whether (TIN - TREQ) is 
greater than or equal to. (TIN j- TOUT), using the sequence 
number subtraction formula described above. If TOUT has 

invalidated, box 118, and 



passed TREQ, j then^ TREQ becomes 
TOUT is reported t,o the client 

To allo f w for flexibility in the client 18 
driver software, jthe client 18! may send data to the 



18, 3j>ox 120, 



server 20 whenever it is convenient 
25 the client 1 ! 8 doe's ,not overflow the 



to do so, so long as 
'server's transmit 



buffer 42 . The procedure for making sure that the 

transmit buffer 42' j does not overflow is shown in FIG. 6. 
I ! . E, -| : . |i !i 

When a 'client 18 wishes to transmit data to a 

port 40, the driver on the client 1|, which is handling 



30" the Communication^ Protocol for 



the <j:lient 18, must 



request that the server 20 open the); port 40 for it, as 
.shown in -box 130.;, /The details of opening a port 40 are 
explained below. After a successful, open, the client 18 
assumes that TSIZE; the size of the? transmit buffer 42 



connected to the open port" 40, | and JOUT are zero, 
addition, the client 18 .resets 1 its own Send Sequence 

i. I • 



In 
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i I 
- Number, which* is a; wrap around sequence number variable 

stored and maintained on the client 18. The -client 18 

then requests TSIZE from the server as shown in box 132. 

Note that the client cannot actually sjend data, as shown 

5 in box 140, until TSIZE is received from the : server 20 as 

explained below. j _ , 

The'; client 18 next determines if data has been 

received f rom^ the host computer j! at t>ox 134. If data has 

i>een received! the jdata must be prepared for 

10 transmission, I box 135. The preparation for transmission 

is later discussed Jin detail. i, | 

j The? client 18 then tests if there is any; data 

to be sent at box nj3 6. If data i is rea'dy to be sent, the 
client's driver must compute the r maximum number of i bytes 
15 that can be accepted by the server 2 0 jwithout overflowing 
the transmit buffer 42, box 138m* This ? is accomplished by 
comparing the ^client's Send Sequence Number with the most 

i ! . 1 

recently reported value of TOUTy and 'subtracting this 

1 \ ' j i i 

difference from TSIZE: ! * 



v 



20 ! [ Max k Bytes to Send = \ 



. TSIZE - (Send Sequence # - TOUT) ) 

3 I ' 1 



Of course, the subtraction of the sequence number TOUT 

t ' j 

from the client's Send Sequence i Number j must be done in 

compliance witih the formula for * Subtracting sequence 

25 numbers. \ I j 1 m 1 | i 

it I ' ! 1 

If tihe calculated maximum number of bytes to be 

'sent is greater than zero, box l4o, then up to that 

number of bytes can be sent to the server 20, as shown in 

box 144. The ^client's Send Sequence Number must then be. 

30 incremented by the number of bytes sent, box 146 • 

Regardless of- whether data has been sent, the 

client 18 must next determine whether the server 20 has "~ 

transmitted the value fbr TOUT or TSIZE, as shown in box 
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15 



148. If so. the value of TOUT or TSIZE as stored at the 

! ! 

client 18- is updated, box 149. 

I f L ! 

To avoid falsely reporting that the transmitter 

is idle when it is not, the server 20 recognizes a very 

| . ! 1' i ^ 

special case. When the transmit buffer 42 is empty, but 

| i t n 

the UART is jstill busy sending in -band data, the server 



10 



20 



25 , 



30 



35 



(TOUT 



1) instead of TQUT. This convention 



client i8 to assume all data has been 



20 reports 
allows the 

successfully sent:, when the client receives TOUT equal to 

I IW ' I ■ 

the Send Sequence Number of the last data sent to the 

server 20. (ll 

The handling of data received from the port 40 

\Y.-\ 3 : 

and transmitted from the server 20 to the client 18 is 

shown in FIG. 7. The server 20 is not authorized to 

transmit data to the client 18 until the server 20 

I , . I i 

receives a .value for RWIN, as .seen in box 150. RWIN is 

! * ? 1 

an Input Sequence and Receive Buffer variable which is 
set by the 
number the 



client, 18 to indicate the highest sequence 

'* 1 i ■ ii ' 

client 18 wishes! to accept. ! 

\ i* j i 

When the; initial RWIN is received from 1 the 
client 18, the server 20 examines the port 40 to see if 
incoming da-ta is available tojbe placed into the receive 

at box 152. |lf data has been r<eceived, 



if.. 



buffer 44, shown 

it is placed in the receive buffer >44 and the RIN 
sequence number is 1 incremented accordingly. This is 
shown in box 154 and box 156. j 1 

- - Because it is not known by the server 20 how 

quickly the client 18 will be j able to receive data from 
the server 
input flow 

-initiated when the- amount of data remaining in the 
receive buffer 44 (calculated! as RIN - ROUT) exceeds the 
value of RHIGH, another Input ; Sequence and Receive 
Buffer. Thus, after data has been placed in the receive 
buffer 44 and RIN has been incremented, the server 20 
determines whether input control shall be' invoked, boxes 



20, the server 20 has the ability to implement 
control on the port 40. Flow control! is 
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162 and 164, Flow control is released when the amount of 
data in the receive buffer 44 drops below Input Sequence 
and Receive Buffer RLOW, which is tested after data_ is 
sent to the client 18 as shown in boxes 158 and 160. 
5 If the review of the port 40 in step 152 did 

not find new data on the port 40, the server 20 - then 
determines whether data is available to be sent in the 
receive buffer 44. if not, as indicated in FIG. 7 at box 
166, the server 20 again waits for data at the port 40. 

10 If data is available on the receive buffer 44, 

then the server 2 0 must compute the maximum number of 
bytes that can be sent to the client 18, at box 168. The 
number is determined by the simple formula (RWIN - ROUT) , 
calculated according to the sequence number subtraction 

15 formula. If the maximum number of bytes to send is zero, 
then the server 20 must wait for RWIN to be updated, 
shown as at query box 170. If the calculated number is 
greater than zero, then the server 20 must determine 
whether it is appropriate to send the data bytes to the 

20 client 18 at this time. Two tests are used to trigger 
the sending of data. The first test, at box 172, 
compares the number of bytes in the receive buffer 44 
(RIN - ROUT) with RMAX, an Input Sequence and Receive 
Buffer which can be set by the client 18. If the bytes 

25 in the receive buffer 44 exceeds RMAX, then up to the 

maximum number of bytes allowed is sent to the client 18, 
box 176, and ROUT is incremented accordingly, box 178. 

If the number of bytes in the receive buffer 44 
did not exceed RMAX, then the server 20 determines if 

30 data has been in the receive buffer 44 at least RTIME 
milliseconds ago and since that time data has not been 
sent to the client 18. If so, then, as shown in query 
box 174, data is sent to the client 18. 

If data is not sent to the client 18-, the data ~~ 

35 remains in the receive buffer 44 until one of the two 
conditions for sending data, ±72 or 174, becomes true. 
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After a^port 40 is opened'; RMAX is initialized 

to one, RTIME to 'zero, RLOW to 1/4 RSIZE, RHIGH to 3/4 

RSIZE and aLll the^ sequence numbers are zeroed. These 

variables however lf» can be altered as i desired. t 
I ■ {• (f 

Generally, the server 20 sends all available 

I < I ; ' f k | ' 

data for each porjt|40 when it sends jj any data for that 
port 40, unless it is restrictjed by j the calculated 

maximum number of bytes that can be sent . This 

! ! * 

convention 
and client 
18 efficiency. 



reduces the number of packets both server 20 
li8 imus^t (process, and generally improves client 



in the host computer, the 
vary - greatly depending 



On the ^client side, 

I : '! 

operation of the jiiivention can 
upon the operating (system of the host computer. For the 

I ' ' | ill 

15 purposes of describing the operation of present invention 

I ■ ■ 1 t i 

on a client 18, tHe implementation on a UNIX host isystem 

will be outlined,! 4 * as shown in Figure 8. The invention 

provides access to I the; ports 40 on the server 20 | through 



the use of 



a' client driver 200 



whic|i implements the API 



of the host (operating system by emulating a driver for a 
set of locally connected serial poris 204. To do this, 



the client 



driver ^200 maintains f orj each remote server 



port 204, an input j or receive buffer 206, an output or 
transmit buffer 20i8, and inf orimation concerning t:he state 

of the remotje seifver 20 as well as the interface I to the 

■ I 1 : ' ' If 

host f computer, which are stored in status memory 210. 



~ j The (driver 200 also 

network interfaces 212 which is 



v 

interfaces to a standard 

• I ; 

connected to the general 



purpose network ro| All communication from the client 



driver 200 
network .10 J 
.connection 
regardless. 



to the' (server 20 id transmitted over the 



35- 



i The network interface. 212. maintains only one 

!i * " ■ I ■ " K ! - 

over the network 10; for jp acl1 server 20, 

of the'>number of pcjrts 4jD that the driver 200 

has open under the : Communication Protocol . 1 

When tliJe j system Is booted; 1 , the operating system 



start-up procedure initializes; the driver 200,- and for 
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eiach server 20 starts* up a user mode dalemon 214 which 
- l * 1i - i - - . -I ' - 

opens -a STREAMS connection 218 to the server 20. The 

daemon 214 then opens a STREAMS connection 220 to a 

control device! 202 associated widh the Uriver 200, The 
Li I 
5 Daemon 214 next, using the STREAMS interface, requests 

that the operating system link the stre'am 218^below the 

control device! 202 so that the driver 200 can directly 

send and receive datja on the network connection to the 

server 20 w/o further interaction! from jthe daemon 214. 

10 By doing so, tke driver 200 is a&le to both transmit 

TCP/IP data to' and receive TCP/IP data !from the server 20 
in the STREAMS \ queue service rout'ine of the control 
device. This eliminates the tas)c switch overhead 
required by the prior art. j < 

15 The connection made is a bytestream connection, 

allowing the driver I200 to reliably senk and received 
sequenced data J to the server 20."^ The driver 200 relies 



connection and 



completely upon the 'reliability of this 

has no provision to Iretry for lost packets and the -like, 

20 Should the driver 2o'o ever detect an error in the data 

received from the server 20, the driver 200 passes a 

hangup signal up to the daemon 21>4, which then closes and 

1 ' ■• ' 

attempts to reopen the connection to the server 20. Such 

an error cannot occur during normal operation. The error 
25 can only occur 1 due t'o a failure , of the remote server 

software, the networking software 4 , the kriver software, 
or some sort of computer failure! The standard TCP/IP 
software in the host computer effectively insures this 
sort of error cannot occur due to: lost or garbled packets 
30 as normally happens 'on a general purpose computer network 
10. I ! ' ' , I . 

Once the driver 200 has access to the network 
connection, the driver requests the server 20 to return 
information as -to the number of serial ports 40 on the - 
35 server 20, and other hardware and software 

characteristics of the server 20. . ~" - 
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When a user mode task 216 attempts to open a 

TTY serial port 204, the host operating- system 215 makes 

an open call to the driver 200. If the port 204 is not 

already open by another user mode task 216, the driver 

sends an open request to the server 20 to gain exclusive 

i h> \ 

access to the port .40 on the server \20 associated with 

1*1 ! : > 

the TTY porjt 204 of; the driver 200. !lf the port 40 is 

available, the seryer 20 responds, granting exclusive 

access to the client 18 until the client 18 closes the 

port 40, or the connection to the client 18 is lost. 

l ^ ■ t f! i 

If the port 40 is not available, the action 

[I 

taken depends on the type of open request originally made 

by the user mode talsk 216. A user mode task 216 !may 

I ■ 'Mi ! > ' J : i 

request that the open fail if it cannot be done 

immediately, or it^may request; that £ the request wait 

until the pjort 4 0i becomes available 

the driver 200 requests an immediate open to the 'server 

I ' "'I f . 1 . \ ' 

j20, which the serjver 20 rejects if the port 40 is busy, 

and the driver 200 ^then returns !an error to the user mode 



In the former case, 



task 216, 



In the latter case. 



it- 



the driver 200 issues a 

8 » 



waiting open, to the server 20, asking to be put on a 



<} t 

queue of waliting clients untilj the port 40 eventually 
becomes available.., The server 20 then returns an 

' ,! " i i . 

indication that the request is queued, and the driver 200 

I '*!!!, ( r 

puts the user mode - task 216 to 

I - 11 I 
notifies the, driver 200 that tl 



sleep until the seryer 20 
ie port 40 is available. - 
Once the driver 200 has successfully opened a 



server port 40, the driver 2 0t) 



sends inquiry packets to 
\ 



the server 120 to learn the hardware] and software 



30" characteristics of the port 40 



including the hertz value 



of the baud rate 'generator, and whether the port j 40 can 



support" mark and space* parity . The | driver 200 also sends 



the server 



35- 



20 the size of the receive buffer 206' for port 

204 so that the server 20 knows how much data can be 

I * " 

received by" the client 18 witliout further, authorization. 



The server 



20 responds to the inquiries, sending the 
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- characteristics of the port 40, and including the size of. 
transmit and receive buffers 42, 44 of the port 40. 

When the driver 200 has received the reply from 
the server 20, the driver 200 is ready to send and 
5 receive data to the port 40, and make control and status 
inquiries on behalf of a user mode task 216, _ when 
requested to do so by the host operating system 
open / close / ioctl (input /out put" control) interface. 
Thereafter, all data received on the port 40 of the 

10 server 20 is automatically sent to the client 18, where 
it is stored in a receive buffer 206. The server 20 is 
initially authorized to send as much input port data as 
will fit in this buffer 206, but no more, so there is no 
possibility of a buffer overrun. 

15 When a user mode task 216 requests to read 

data, the host operating system calls the read routine of 
the driver 200. If sufficient data has been received 
from the server 20, according to the parameters of the 
read request, the driver 200 returns that data to the 

2 0 host operating system 215 which in turn passes the data 
to the user mode task 216. If sufficient data is not 
available, -the driver 2 00 puts the user mode task 216 to 
sleep until the data arrives, or until the read request 
times out or is interrupted according to the API of the 

25 host operating system 215. 

After the driver 200 has removed data from the 
receive buffer 206, the driver 200 informs the server 20 
that this data has been removed by incrementing a 
sequence number (RWIN) by the number of bytes removed, as 

30 described above. The server 20 is then authorized to 

send additional data until that data reaches the sequence 
number RWIN. 

When a user mode task 216 requests to write 
data, the host operating system 215 calls the- write 

35 routine of the driver 200. If the driver 200 then, copies 
as much of the user data as will fit into the transmit" 
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buffer 208, 



If all of the dat l a could be placed in the 



transmit buffer 208, the server 20 completes the request, 
and the user modej.,task 216 is allowed to continue.' If 
not all of the da-ta fit in the transmit buffer 208, the 

V 1 ■ 'I 

driver 200 puts the user mode jtask 216 to sleep until 
data can be sent Jto the seryerj 20, freeing up enough 
space in the transmit buffer 208 so the remaining data 
can be placed in ! ^the buffer 1 20,8. 



When a fuser mode task 216 



makes a control or 



10 inquiry request (known as an ioctl request), the. host 

1 1 ! •! 1 1 I . 1 

operating system f2l5 calls the' ioctl routine in the 

I : »'"!'( • I l 

driver 200 j ; If Che request 1 isi to change the hardware or 

II I- 1 ■ 1 \ 

software characteristics of : the port 204, the driver 200 

I j ■!■; ! I 

notes the change j-in the status! memory 210, and sends a 
command to the se'rver 20 to.majke the necessary changes. 
If the request is tan inquiry request which the driver 200 
can Respond | to wi|fcljiout consul tjing t^ie server 20, the 
driver 200 



the server 
the server 



Will dOjjso.j If the request requires data in 



20, the i driver 200 



sends 



20 for .this information and uses the 



information returiaed to satisfy the 



mode task 216. The types of requests that can be made by 

i 

user mode tasks 216 are very diverse, and the action 



takes varies wide'ly. in some 

. ! j ;| '' : 

satisfied immediately, and in 
task 216 must be 
completed. 

When a 



to the TTY 



jput to sleep 



cases 



until 



-user mode task 216 



an inquiry request to 



request of the user 



the request can be 



! 



some cases the user: mode 



the request can be 



port 2(04, the host 



makes the last close 
operating system calls the 



close routine : of | fche driver 200. This causes the driver 
"200- to put the.us^r mode task [216 .tt> sleep, to wait until 
-all the data in the transmit buffer' 208 has beeni 

i ' ; • 1 ./* i ; 

transmitted and toi wait until ( any pending request to the 

I M i ! 

server 20 are ; complete. The driver.! 2 00 then sends a 



35-- close request to 



ithe server 20. Upbn receipt of the 



close request, the] server 20 de-allpcates the port 40 and 
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-possibly reallocates it to another client 18. The driver 

200 then completes the close, sLri'd the' user mode task 2*1 S. 

continues. \ \ ^ 

To optimize the efficiency of the operations of 

5 the driver 2 00;, and minimize tJtie'J load on the host 

*~ 1 1 I 

operating system 215, driver 200' 1 communications .to the 

server 20 are made kt. periodic iiitervais about -fifty 

times/second. ! At each such interval, tlhe driver 200 

inspects each active port 204 that is open to that ' server 

10 20, and places' requests and data for aljl such ports 204,'- 

40 into a common message, and s ! £hds that message to the 

server 20 as al single operation." This 'action minimizes 

the total number of ] TCP/IP messages (or other general 

sent to the server 



purpose network messages) that must be 



15 20 , and so enhances 

It should 

I. 



the operation of the system 
be recogniz'eci that 



the current 



invention provides a protocol which cdn be used to 

1 ■ j 

simulate serial port hardware across a 'network 10. 1 When 

used in this manner] a board or! "other hardware is -~ 

20 installed in d host ' computer in' such a way that it 

provides a serial port interface 'to tlie' host computer 

similar to a local Serial port bbard. ' lln this 

i I 1 ' 

embodiment, the board contains a* 'general -purpose network 

l t j t I 

protocol stack, m addition to other software that 

i I i 

25 provides the serial Iport interface and ,the functionality 
described above in connection with the 'client driver 200. 
Using this board, drivers can be 'used on the host 
operating system that are aware' ! bf only' a serial port 
interface, and I are unaware of thfe existence of the 

30 network 10. * 1 . f 

Such 'a hardware implementation, has several 
advantages. First, it can be used to emulate a hardware 
or software interface for which drivers are already 
available (or- can easily be adapted) on the host 

35 operating system. Second, the board can be -installed in 
a computer where networking hardware or .sof tware is not * 
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readily available, thereby providing network services to 

! ■ T 

the host computer.- Third, the board can include an 

additional processor and hardware which off-loads much of 

; ' ' j 

the serial port overhead onto the card. Finally such a 
card could be multi-functional' in nature by containing. 



\ 

physical devices that 



for example,: a small number of 

could eithe'r be reserved for the local ; computer or be 

network accessible. 1 I ; 1 

I Mi ■ I ■ 

All information, including data and commands, 
I ■ M- IT 

exchanged between the server 20 and t the client 18 is sent 

! ■ It,* I * I > 

over the byte stream provided by the network protocol m 

small units called packets. ' The format of these i packets 

makes up the 

invention. 

simiiar in 

that the fi 

format and 



Communication Protocol of the present 

The Communication Protocol packets are 

!*'■ ! i I I 

format^to CRT terminal escape sequences, in 



r'st few bytes of the sequence determine the 

| ; ? 1 ! |li , ■ 

length, (bf the data that follows. ! 

I I 1 !' ' I I j 

The creation of the packets for communication 

I i ■ I'^'i i I 

from the server 2(0 [to the client 18 takes place in the 

CPU 32 of Jhe server 20. Packets that are sent from the 

I ! r'<! 1 i I ' fi i . , 

client 18 to| the server 20 are created by the special 



driver operating on the client 



themselves 



18. ^ The packets 



have a variable format and variable length, 
depending on the type of information they contain. The 
25 i format of ea'ch packet is determined'' by processing it 
: sequentially. The lvalue of earlier bytes completely 



determines 
follow. 



t 4 ! 

the format and content o£ the bytes that 

i Ms | 



V r 
9. .shows the different types of packets 



Table _ 

I 1 ' P- ! » ■ 
which can be! sent between a server 20 and a client 18. 



The -table shows how the first byte breaks down a packet 



I 



into major 



invention. 



subtypes 



Values denoted illegal were hot 

r i( 5 •■ I i I * 

supported in the [preferred embodiment of the present 



it 



Data packets are used to send all in-band data 



between: the client 18 and server 20. When received by 
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the server 20, the data in the data packets are - 
transmitted through to the appropriate port 40 as 
described above. 

Window sequence packets inform the receiver 
5 about the state of the sender's sequence numbers. The 

transfer of this information is essential for the working 
of the data flow control of the present invention, as 
outlined above. Window sequence packets are used by the 
server 20 to send TOUT to the client 18, and are used by 

10 the client 18 to send RWIN to the server 20. 

Command packets have different formats and 
different lengths depending on the value of the command 
type field in byte one.' Commands are sent to set and to 
query about the values of the server state variables 38. 

15 In addition, command packets are utilized to open a port 
40, allowing the client 18 to guarantee synchronization 
with the server 20, to ascertain the size of the server 
transmit and receive buffers 42, 44, to ascertain the 
capabilities of a particular port 40, to flush the 

20 buffers 42, 44 of the server 20, to send a break or an 
immediate character and to pause or restart input or 
output. The command packets implemented in the preferred 
embodiment are set forth in Table 10. 

Two of the most important command packets 

25 involve communication between the client 18 and the 

server 20 in connection with opening a port 40. The Open 
Request command for opening a port 40 is sent by a client 
18 who wishes to obtain exclusive access to a port 40 on 
a server 20. When the server 20 receives an Open Request 

30 command, the server 20 attempts to open the port 40 for 
the client 18 and then responds with an _0pen Response 
packet which informs the client 18 of the results of the 
open attempt. 

The -format of the Open Request Command Packet ~~- 

35 and the Open Response Command Packet are set forth ^in 
Tables -11 and 12 . 
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The command packet to open a port 40 can take 
different forms, depending on which j type of open command 
is desired by the .^requesting ^client j 18 . The possible 
types of open commands are an immediate open, a 
persistent Open, an incoming open, jj 

Aj request for an immediat^ open succeeds, and 
the port 40| is assigned to the j reques ting client 18, only 
if the port 40 is^valid and immediately available. If 



the port 40 
fails . 



is not", immediately, available, the request 



When a persistent open request is made, the 
request will, succeed and the port 4(jj will be assigned to 
the client 18 if fc^he port 40 is available- If the port 
-40 is busyj the server 20 returns ari Open Response packet 
to the client 18 which indicates the port 40 is busy, and 

ii-; • ; 1 1 

then places the client 18 on aj waiting list for that port 
40. When the port j40 subsequently tpcomes available, the 
port 40 is opened, ' and the client 18 is notified with a 

Z ' i !l • „■ 'J.i ' IS 

Response indicating success. i i 



second Open 



an incoming 
the port 40 



The thi:r;d type of, [open rec^uest is a request for 
This request succeeds immediately if 



open, 



1 , 



is available, and a carrier is present on the 

port 40. If the port 40 is busy, or if a carrier is not 

I i ' 1 : 

present, the servjer 2 0 returns > the corresponding Open 

I i ' ' f ' 

Response" code and places the client 
for that po^rt 40.J^i;When the port 40 
available with carrier present I the 



and the client 



indicating 



success , 



18 on a waiting list 
subsequently becomes 
port 40 is opened, 



is notif ied~with a second Open Response 



A clien,t jl8 may also) send 



a cancel waiting type 



of Open Request f^z- a particular poi|t 40. When this 



command' is [received from a client 

i pr 1 1 ; - - 

checks to see if |t-lie client ,18 



18, the server 20 
is oijj the waiting .list for 
o;. If = the client 18 is found on the list, the 
s removed, and the server 20 returns ani Open 



that port 4 
client 18 i 

Response indicating success 
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I It is possible to orgathize ports 40 on a server 

20 into a port! hunt 1 group, - When 1 this "is done r the server 
20 provides one or. more logical ports designated as hunt 
group ports soj that* any attempt ''to open one of these 

configured as a 



5 ports in fact iopensj a physical port 40 

member of the E hunt group. Thus/ if a client _18 .requests 
a port 40 which is part of a port hunt group, the actual 
port 40 opened will! be dif f ererit j f rom the port 40 

1 i i if i 

requested. The client 18 must inspect the PNUM portion 
10 of the Open Response after a successful, open, and use 
that port numb'er for all subsequent references to the 
port 40. 3 1 : <t* 

The Synchronization Request command causes the 

! . . il S 1 '1 'I 

recipient to respond with a Synchronization Response. It 

15 has no other effect 1 . 'The primafry purpose of this command 
is to allow thfe client to guarantee synchronization with 
the server. For example, a client 18 may wish to confirm 
a! requested baud rate change before returning to the 
calling program. The client 18' achieves this by f irst 

20 sending a baud! rate change to the server 20, and then 

following it wkth a' Synchronization Request. Since the 

I ! i j j 

server 20 processes 1 commands sequentially, when the 

1 i I i 

client 18 receives the matching the Synchronization 

Response, the client 18 can be 'confident the baud rate 

25 change has been accomplished. ; h ; 

The Sequence Request £md Response Packets are 
provided so the client 18 can accurately track the flow 
of data in and out of the server/ 20. The server 20 ' 
responds to this packet by providing RIN and TOUT to the 

30 client 18 . I 

The client 18 may send a Status Request Packet, 
to discern the' current state of ESTAT and MSTAT in the 
server 20. The server 20 returns the requested data in a. 
Status Response Packet, and takes no other action. . This ~~ 

35 command is one J of two ways the client 18 may learn the 
status of server 20. The client 18 may .also use the 



WO 95/25311 



PCT/US95703183 



37 - 

i _ 



10 



15 



20 



1* 

Select Event Conditions Packet to have the server 

■i. i 

automatically report selected status changes as they 



occur. 



t 



The client 18 sends the Line Error Request 
5 Packet to poll the line error counters, to configure 

periodic reporting of line error counters, and to clear 



the counters J 
in response 



The. server 20 sends a Line Error Response 
to a poll for the error counters, and also at 



I 



periodic intervals as configured with the variable LTIME. 

All Line Error Request packets 'may set the server 

1 i » r. i I 

[variable LTIME. An LTIME value of 0. disables automatic 

I i i* i 



Reporting, 
.unchanged. 



An LTIME value of FFFF leaves LTIME 



i 



r 



Aftier the client 18 has set LTIME non-zero, 

j _ I; f 



the 



t 



^server 20 inspects, the state of the .error counters every 

; LTIME milliseconds j '(to an accuracy o|f approximately 2 0 

■ | ' 1 1 f t I ' 

.^milliseconds), and j^ends an automat icj Line Error Response 
/packet if they hayej changed since the last report. 

is sent by the client 



The Buffer Request Packet 

the size of the server transmit buffers 42 



18 to learn 
and receive 



buffers; 44. The server 



20 responds with the 



Buffer Response Packet. Af ter |a successful open, and 
before sending data 1 to the server 2o' the client 18 needs 
to ascertain the size of the server's buffers 42 ,\ 44. 



25 The size" of 



the transmit buffer 42 is needed so the 



client 18 can know 1 how much data the client 18 is allowed 

I 1 " H I! ! 

to- send. The size of the receive buffer 44 is needed so 

! 1 - I 

the server 20 can set the flow control high and low water 



marks accordingly. 



30 ' 



sent- by the 



The Port capability request packet is generally 
client 18 to learn j the capabilities of the 
hardware and software of a port 40. ' Unlike other port- 
level commands, the; port 40 need notj be open when this 
command is issued. 
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The Set Baud Rate command is used by the .client 
18 to set the port baud rate, CFLAGS, I FLAGS, -OFLAGS and 
XFIiAGS of a port 40. 

The client 18 sends the Select Event Conditions 
5 command to specify which ESTAT and MSTAT conditions cause 
the server 20 to send an Event Packet. The client may 
also poll for ESTAT and MSTAT using the Status -Request 
Packet. 

The Set Window Trigger command allows the 
10 client 18 to set TREQ, one of the server status variable 
38. TREQ is the client 18 requested level at which a 
Window Sequence Packet should be sent. If TREQ is 
outside the range of data currently in the output buffer, 
the server 2 0 immediately responds with a Window Sequence 
15 Packet. 

The Set Modem Outputs and Flow Control packet 
is sent by the client 18 to set modem outputs, and select 
modem-signal hardware flow control. Note that when RTS 
and DTR modem flow control are selected, the values of 

20 RTS and DTR in MOUT are ignored. 

The client 18 sends the Set Receive High/Low 
Water Marks packet to set receive flow control high and 
low water marks. When this packet is processed by the 
server 20, if takes effect immediately. If the number of 

25 characters in the input buffer exceeds RHIGH, flow 

control is immediately invoked. If less than RLOW, flow 
control is immediately released. 

The client 18 sends the Set Flow Control 
Characters packet to set server 20 software flow control 

30 characters. Similarly, the client sends the Set RMAX and 
RTIME command to set the parameters RMAX and RTIME and 
the Set TMAX and TTIME command to set TMAX and TTIME . 

The client sends the Send Character Immediate 
packet to send a character ahead of in-band data. In 

35 sending immediate data, software flow control is ignored, 
and hardware flow control uses the variable MCTRL instead 
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of MFLiOW « 



The client 18 utilizes the Send Break 



Immediate joacket send a hardware ^ break signal, ,j The 

Break signal is aiso sent ahead of all in -band data, and 

regardless jof software or hardware | lo V control, j 

Tjhe client sends Flush Buffers packet to, flush 

either or fc>oth thje ; server inpup and | output buffers. The 

Pause Input/putpujt j packet pauses any set of software flow 

control condition's. ! in the server. it is ineffective to 

attempt to pause input if the number of characters m the 

I! i ! ! ! . 

receive buffer isp.Iess than RLOW. Finally, the Unpause 

Input/Output^ packet! is used to! unpause any set of j| 



software fl 
ineffective 
characters 



oyt control conditions in! the server. 

^T! ■ ! J 



It is 



to attempt to unpause input if the number of 
iii theLreceive buffer is j greater than jRHIGH. 



Event packets are sent by 



inform the 
conditions 



I 

client 
' The 



18 of changes ; in 



the server 2 0 to 
ISTAT and MS TAT, 



server 20 sends an f event packet 'for each 



port |40 whenever :/^( ETRAN r & EINT) or | (MTRAN & MINT) are 



non-zero. 

i ! 



i 



NjT) 



I To| assume this requept does not cause \ j t 

transitions to, be ^ost i that would otherwise be repiorted 



in event pajcjkets , j^the server 2p first sets ELAST and 



MLAST as fallows, 
client 18 . 



ELAST 

i ! 
ETRAN 



MLAST 



particular 
bandwidth , 



(ESTAT ~ ELAST) 
ESTAT A ELAST 

i 

= | (MSTAT ^ MLAST) 
* ! 

MLAST 



.and then reports ELAST and MLASTu to the 



i j* 

(ETRAN & EINTi) 



(MTRAN & MINT) 



MTRAN MSTAT 

' I 
I I 

Module jgjeslect Packets arejlused to select^ a 
gjrpupixig of ports 4p . T<p reduce communication 
40 are logically grouped into modules, 



pprjts 



i 



with each module .containing only sixteen ports 40 (ports 



0-15). -There need be no relationship between a logical 
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! j j 

module grouping and t the physical:' layotit of the ports 40 

I i * i>\ . - i " * - * 

on the server (s) . By grouping : ports 40 into modules, the 

addressing in :all commands and responses references .need 

to only refer to which port (0-lJ5) is desired within the. 

5 current module. Module 0 is selected iby default. 

Modules 0-7 can be selected with a one byte module select 

packet. Modules 8-255 require ta two-byte packet. It is 

possible to convert between a module and port pair and a 

■ I I ; ! i. i ! 

physical port number. When module n is selected, port K 

\ ' ' i ' 1 

10 in all subsequent packets refers' to physical port 16*n+K. 

I i I ' • j 

An ID request packet ; is sent by either the 

client 18 or sjerverj 20 to get identity or configuration 

information from the remote. Tlie remptle responds with a 

corresponding ID response packets! ' I - 

15 The idebugging packet types supports access to 

\ ' i • I 

ports 40 of the server 20 for debugging purposes, such as 

I ■ i : I 

transmitting debugging data between the client 18 and 

server 20. These packets could also be used to allow the 

client 18 access to the server 'program ^memory 36, either 

20 to review the contents of program memory 3 6 or to change 

the programming of the server 20 t as stored in program 

memory 36 . ^ , | ! ! 

! The reset packet type 'is send by a client 18 or 

J i 1 

server 20 to report ; a protocol error to the remote, prior 

25 to shutting down the connection: 1 The placket contains an 

explanation of! the reason for the reset' in an ASCII 

i < i 

format. The Reset- Packet should be the last packet sent 

in a conversation. ^ I 

Although this discussion has not specifically 

30 covered operating systems other 1 than UNIX, it will be 

obvious to one! skilled in the art that ( there are features 
documented in XFLAGS, the error 'counter's and the event 
flags that are required to satisfy the application 
programming interfaces of Novell", Windows, Windows NT, 

35 OS/2 and DOS. As a result, the 1 implementation of the 
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invention in any of these operating systems is obvious to 

one skilled in the art. 

. ^ ' I 
The invention -is not to be taken as limited to 

all of the details thereof as modifications and 

variations; thereof may be made without departing from the 

spirit or scope of< the invention. \ 

Hi, 5 f 



Mi 
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Table 1: Server State Variables 



10 



15 



Type of Server State Variables Frequency 

Client Connections per server 

Message Build Interval per server 

Port Open State ~ per port 

Port Baud Rate per port 

Processing Flags per port 

Flow Control Characters per "port 

Modem Control per port 

Line Error Counters per port 

Send Break and Send Immediate per port 

Event Reporting per port 

Input Sequence and Receive Buffer per port 
Parameters 

Output Sequence and Transmit Buffer per port 
Parameters 
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Mask 
0001 
0002 
0004 

0040 
2000 



Table 2: XFLAGS Settings 

Name Description 

XPAR Enable Mark/Space parity. 



XMODEM Enable in - band | modem signaling. i 

XCMlSE ! Convert special characters to multiple- 
character sequences on output . 



XTOSS 



Toss IXANY characters , 



XIXON Enable a second set of Output Software Fl 
Control Characters . 
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! 



Name 
MOUT 
MFLOW 
MCTRL 
MSTAT 
MLAST 
MTRAN 

MINT 



! Table 3 : Modern^ Variables 

Description ' . 

Client specified modem output values. 
Mojdem flow control for in -band data. 



Modem flow control for out- 
Current modem status. 



of -band data. 



Last modem status sent to the client. 

Sef of modem signals which jhave changed, but 

i 

those changes have not yet jbeen sent to the 
client . 

Modem signal, changes' to be Reported to the 
client. 

» t - 



SUBSTITUTE SHEET (RULE 26) 



WO 95/25311 ? 1 PCT/US95/03183 



- 45 





TaDie 


4 s NOQcin o3.Gfna.xs xn noaem variaDies 


Mask 


Name 


T"^ a. a t t"\ 4- I r*\ "r\ 

UBScripLion 


01 


DTR 


Data Terminal Ready. 


02 


RTS 


Request To Send. 


10 


CTS 


Clear to Send. 


20 


DSR 


Data Set Ready. 


40 


RI 


Ring Indicator. 


80 


DCD 


Data Carrier Detect. 
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Table 5: Event Reporting Variables 

Description 

Current state of event conditions. 

Last state of the event conditions sent to the 
client. _ 

Set of event conditions which have seen - 
transitions, but those transitions have not 
yet been reported to the client. 

Set of event conditions which cause an event 
to be generated. 
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10 



Mask 
0001 
0002 

0004 



Name 

i 
l 

OPU 
OPS 



OPX 



0008 


OPH 

1 


0010 


1 

IPU 


0020 


IPS 


0040 


TXB 


0080 


TXI 


0100 


TXF 


0200 


RXB 



Table 6 : Recorded Events 

i 1 

Description 

Output paused unconditionally by client 
Output paused by regular software flow 



t 



control . 

Output paused by extra software flow control 
characters . 

Output paused by hardware flow control . 

hi t 
Input paused unconditionally by client. 

Input paused by high/low water marks. 

Transmit break pending. 

Transmit immediate pending. 

Transmit flow control character pending. 

Break received. 
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Table 7: Input Sequence and Receive Buffer Variables 

Name . Description ~ - 

RIN Sequence number of this next byte of data to be 
reah from the UART and placed in the local 
receive buffer. 

ROUT Sequence ; number of the next byte to l>e 

transmitted from the .receive buffer to the 



10 



RWIN 

RMAX 
RTTME 
RSIZE 

RLOW 
RHIGH 



client, i | 

Highest Sequence number the ,client wishes to 
accept . j 

Receive trigger maximum. 

Receive trigger time. 

Size of the local receive buffer. 

Software flow control low water mark. 

Software flow control high water mark. 
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Table 8 : Output Sequence and Transmit Buffer Parameters 
Name Description 

TSIZE Size of the transmit buffer in bytes. 

TIN Sequence of the next byte to be placed in the 
transmit buffer. 

TOUT Sequence of the next byte to be sent from the 
transmit buffer out the port. 

TPOS Value of TOUT last reported to the client. 

TMAX TOUT report maximum. 

TTIME TOUT report time (milliseconds) . 

TREQ Client requested sequence number. 



hi 
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Table 9 : Packet Types. 
Nibble 0 Nibble 1 Description • ~ 

0 port 0-15 Data Packet, 1 byte of data follows 

for the specified port. 

1 port 0-15 Data Packet. 2 bytes-of data follow 

for the specified port.* 

5 2 port 0-15 Data Packet. 3 bytes of data follow 

for the specified port. 

3 port 0-15 Data Packet. 4 bytes of data follow 

for the specified port. 

<* 

4 port 0-15 Data Packet. 5 bytes of data follow 

for the specified port. 

5 port 0-15 Data Packet. S bytes of data follow 

for the specified port. 

6 port 0-15 Data Packet. 7 bytes of data follow 

for the specified port. 

10 7 port 0-15 Data Packet. 8 bytes of data follow 

for the specified port. 

8 port 0-15 Data Packet. Byte 1 of the packet 

specifies 1-255 bytes of data 
following for the specified port. 

9 port 0-15 Data Packet . Bytes 1-2 of the 

packet specify 1-65535 bytes of data 
following for the specified port. 

10 port 0-15 Window Sequence Packet. Bytes 1-2 

specify a window sequence number. 

11 port 0-15 Command Packet . Byte 1 specifies a 

command number which determines the 
length and format of the data that: 
follows . 
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10 



Nibble 0 
12 

13 
14 
15 

15 

15 
15 

15 

15 
15 

_-15 



Nibble 1 
port d-15 

>j 

* f 1 ! i 



Description 1 

Event Packe t . 
follow. 

Illegal r , 

Illegal*. 



3 bytes of status 



module 1 0-7 Module select Packet 



Nibble 1 



I* 
■'I 

8 'H 

\ ;ij 

9 -id 
li 

12 

13 
14 

15 



I 



contains the f; module number to be 
selected. ) l f , 

Module select Packet . Byte 1 

I 

specifies a module select code in 
the range 0-255. 

Illegal). ? 

ID Request packet . Requests an ID 
response . 

ID Response packet . Byte 1 
determines the size of the data 
which follows. 

Debugging and Control Packet . 

Debug Packet . Specifies a number of 
following bytes to be utterly 
ignored. Used for stress testing. 

Reset Packet . Followed by a null- 
terminated ASCII string describing 
the reason for. the reset. 



$* sr WK sneer mE!6) 
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Table 10: Command Type Assignments & Lengths 

. i . • " ■ \ - j " . ' 

Command Type! Command Length u Command Name 



(byte 1 value) (bytes) ' I 

i j ! 

! i i 

10 3 t'Open Request 

11 6 \ ^Open Response 

" ! 4 \ 

12 3 Synchronize Request 

1 ! V H I 

13 3 Synchronize Response 

14 2 Sequence Request 

15 6 'Sequence Response 

Request 



10 16 2 ^-Status 

» i 

17 5 1 'Status 



Response 



i • i 



18 6 ".Line (Error Request 

: ! - ■ I 

19 14 Line Error Response 

• »'•! I 

20 2 Buffer Request 

15 21 6 1 , Buffer Response 

! S , 

22 2 !: i^Port (capability Request 

23 t 32 MiPort Capability Response 

4 0 12 r ,Set Baud Rate ' CFLAGS, 

'iFLAGSl, 0 FLAGS and XFLAGS 

: , <>< : i 

42 5 Select Event Conditions 

if 1 i 

20 43 4 ; >JSet Window Trigger 

44 » 5 i f jSet Mo'dem outputs and Flow 

*jControl 

45 6 jSet High/Low Water marks 

46 7 r Set Flow Control 

7l Characters 
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Command Type 
(byte 1 value) 

47 

48 

60 

61 

62 

63 

64 



Command Length Command Name 
(bytes) 



6 
6 
3 
4 
3 
3 
3 



Set RMAX and RTIME 
Set TMAX and TTIME 
Send Character Immediate 
Send Break Immediate 
Flush inpu t / ou t pu t 
Paus e i npu t / ou tpu t 
Unpau s e i npu t / ou t pu t 



SUBSTITUTE SHEET (RUtE 26) 



WO 95/25311 



PCT/US95/03183 



Table 11: Open Request Packet 



Position 


Name 


DescriDtion 




Nibble 0 


MTYPE 


Message type 11 : 


Command . 


Nibble 1 


PORT^ 


Port number 0-15 




Byte 1 


CTYPE 


Command type 10: 


Open Request. 


Byte 2 


REQ 


Request Type: 








0=lmmediate 


open 



l=Persistent open. 
2=Incoming open. 
3=Cancel/Close immediate open 
4=Cancel/Close persistent or 
incoming open . 
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Position 
Nibble 0 
Nibble 1 
Byte 1 
Byte 2 



Byte 3 



4< 

Name 
MTYPE 

PORT 
CTYPE 

REQ 



Bytes 4-5 



Table 12 : Open Response Packet 

Description 

Message type 11: Command. 

Port number 0-15. 

Command type 11: Open Response, 

Request Type : j 

0=lmmedipte open 

l=Persistent open. 

J 

2=Incomxng open. 
3=Cancel/Close immediate open. 
4=CancelVciose persistent or 
incoming' open. 

RESP Request code: 

0=Success . 
1-Port busy. 
2=No carrier. 

3=Resource allocation problem, 
try again. 

4=Request not supported on this 
device . 

PNUM Actual port number (16*module+port ) 
opened by this request . 
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' " Claims ' - _ - 

A system for communicating digital data comprising: 

a) a general purpose computer network; 

b) a host computer operably connected to the 
general purpose network having an operating 
system t with an application: programming 
interface for a local communication device; 

c) a device driver mean's running on the host 
computer for implementing the application 
programming interface of the local 
communication devicei and transmitting 
operations requested by the application , 
programming interface over : the general . purpose 
network; and \ 

d) an apparatus operably connected to the general 
purpose network having 

i) at least one communication device, and 

ii) an implementation means for implementing 
the operations requested by the 
application programming interface and 
transmitted over the general purpose 
computer network by the device driver 
means . 

The system of claim 1, further comprising device 
entities visible through the application programming 
interface, and wherein there is a one-to-one 
relationship between the device entities and the 
communication devices on the apparatus. 

The system of claim 1, wherein the device driver 
means implements the application programming 
interface of the local communication device by 
utilizing a TTY device on the host computer for 
receiving and transmitting data to the operating 
system operating on the host computer. 
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The jSystem of claim 3, wherein the operating system 



is UNIX. 



The jSystem^ of claim 3, wherein the operating system 



is Novell Netware. 

1 ■ ■ r i 



5 6 



10 



15 



20 



25 



8. 



9. 



The [System 'of claim 1, wherein the device driver 



means further comprises 

I ■ i • } t ' r 

a) local implementing means for implementing the 



S 



operations of the application programming 



b) 



i interface which can be done locally are done 
locally at the host computer, and 
remotje jimplementing means for transmitting the 
operations of the application programming 
inter-face which alter hardware characteristics 

: ■ i r . . ! 

of the communication device over the general 
purpose network to the apparatus for 
[implementation by the apparatus , 



The 



: !| it 'f 

systemvjOf claim 6 wherein 



the remote 



implementing means further comprises transmitting 
portion of^the operations of jjthe application 
programming interface which could be done locally 
over the general purposie network to the apparatus 
for | implementation by the apparatus m order to 
reduce 'the processing load on the host computer. 



The 



system^, of claim 1, wherein the apparatus is 



located physically distant from the host computer. 



The 



system, of claim 1, wherein the device driver 



means' is a:« serial communication driver. 



10. . The j system^ of claim 9 wherein the device driver is 
an asynchronous serial communication driver. 
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- 11. The system of claim 1, wherein the apparatus^ further 
- comprises a plurality of communication devices. - 

12 . The system of claim 1 wherein the apparatus further 
comprises at least one serial port . 

5 13 . The system of claim 1 wherein the device^ driver 
means on the host computer communicates with the 
apparatus over the general purpose network through a 
reliable bi-directional bytestream connection. 

14. The system of claim 13 , wherein the reliable bi- 
10 directional bytestream connection is a TCP 

connection. 

15. The system of claim 14 f 17, wherein the bi- 
directional bytestream connection is a single 
bytestream connection which supports communication 

15 between the device driver means and multiple 

communication devices on the apparatus . 

16. The 'system of claim l, wherein the device driver 
means further comprises open requesting means for 
requesting the communication device to grant to the 

20 host computer exclusive access to the communication 

device on the apparatus. 

17. The system of claim 16, wherein the open requesting 
means further comprises requesting the apparatus to 
place the host computer on a waiting list for the 

25 communication device where the communication device 

is not immediately available for the exclusive use 
of the host computer. 



The system of claim 14, 17, wherein the open, 
requesting means further comprises requesting the 
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apparatus to grant the host computer exclusive use 
to the communication device if the communication 
device is available and a carrier is present on the 
communication device and wher 5 e the communication 
device plac.es the host computer on a waiting list 
from | which the host computer is removed and given 
exclusive access to the i communication device when 
the communication device is available and a carrier 
is present on the communicatipn device. 



10 19. The system ho f claim 16, : further comprising at least 

I -HP i ! 1 

j one additional host computer pnd wherein the 

apparatus grants exclusive acpess to the 

communication device to j a particular open requesting 



15 



20 



25 



20 , 



means of a 
particular 



iparticular host computer when the 

^ppen requesting means requests access to 



means 



the communication device and jjthe communication 
device is available, j 



The system, of claim l> wherein the device driver 



comprises a device driver installed into the 



UNIX, kernel. 



21. The system 

| [ i 

daemon means 



connection 
apparatus , 



^ ; ! 

\\d£ claim 20, j further comprising a UNIX 

1 I 

for establishing a reliable bytestream 



over the general purpose network^ with the 



device associated with 
utilizing the STREAMS 



opening a control 

the Idevicei driver means', and 

llli.il. 
interface to 1 link the reliable bytestream cpnnection 

I M 1 'I 1 

to the device driver means such that an application 

l i . i ; . 1 

program] isi not needed to senc 

the 



connection, 



and receive data over 



30 22. .An imprpvep jterminal ^server cj>f the type for 

providing access to a host computer through a 



gene'ral, 1 purpose network, and ; having a network 
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j j : ( 

interface device connected to the. general purpose 

network for deceiving and transmitting- data across 

the general purpose network and also having a 

■i 

plurality of communication devices available for 
communication with the host computer, the 
improvement comprising: j _ 

a) a 'communication protocol rich enough to support 

•'■ i ' ' ! 

all the] common hardware and software operations 

j ' ' ' 

supported by the application programming 

interface of widely '^available operating 

systems; ; 

b) a (translation means^for translating data 
received from the ge'neral purpose network 
accordingj to the communication protocol; 

c) an implementing means for implementing the . 
operations translated by tJie translation means. 

! ! 1 'nj 1 | 

1 t .it' 

The system of claim 22, further ! comprising : 

d) a data transmission control means for combining 
all data to be transmitted j from the 
communication devices to tlie host computer into 
a jsingl'e tyte stream protocol transmission 
adross the general purpose network. » 

J I ■ i ! ! 

The system of claim 22, further comprising: 
d) flow control means for controlling the 

individual communication devices is independent 
of the flow control v'f or the reliable bytestream 
connection. 

: .' : i ?1 

A method for transmitting data and commands from an 
operating system running 'bn a host computer to a 
serial devicfe attached to a terminal server across a 
general* purpose network, "the method comprising 
a) receiving data and commands directed toward the 
network device from the operating system so 
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10 



15 



20 



25 



30 



b) 



c) 



d) 



e) 
f ) 



g) 



h) 



i) 



that the operating system acts as if it is 
communicating with at least one locally 
connected device; 

storing the data and commands received from the 
operating system in a host receive buffer; 
formatting data 1 ! and commands into a plurality 
of packets according to a protocol; 
transmitting the t packets? from the host computer 
to the terminal server across the general 
purpose network utilizing a reliable, bi- 
directional byte stream connection ; 
receiving the packets at the terminal server; 
translating the ipackets received at the 

terminal server into the 1 data and commands sent 

i | ; ; 

by the] operating system;; 

i ! ' i r 

storing the data in a terminal server transmit 

buffer.;' | t 

performing the operations requested by the 

Commands sent by the operating system; 

• I ! 1 : i i I 'i 

transmitting the data stored in the terminal 

i ! ; ' 1 ' I 

server transmit' buffer to the serial device. 



26. A system for communicating data comprising 



a) 
b) 
c) 

d) 



a general purpose network; 

a host, [computer .operating on the network; 

i ' r f . : ■ ■ i \ 

a communications server operating on the 

i | 1 i ; : ; 

netwoirk; 1 ! 

a device driver means operating on the host 
computer for providing a set of device entities 
which appear to applications running on the 
host computer -to be local devices and which are 
actually located on the i ! communications server. 

: I IT 1 I ■ . 
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BEGIN TRANSMIT 
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Fig. 5 



104 



PLACE DATA IN BUFFER 
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_ YES 



108 



-^10 
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TO TOUT 




122 
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130 



Fig. 6 



REQUEST TSIZE 
FROM SERVER 



132 



136 




134 



YES 
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PREPARE DATA FOR 
TRANSMISSION 



138 



YES 



COMPUTE MAX NUMBER 
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NO 



148 



NO 



149 
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144 
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146 
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6/7 



Fig. 7 
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156 
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CONTROL 



WO 95/25311 



PCT/US95/03183 



216 



7/7 

Fig. 8 



USER MODE 
TASK 



215 



HOST 
OPERATING 
SYSTEM 




USER MODE 
TASK 



HOST 
OPERATING 
SYSTEM 



204 



TTY1 



206 



c 



208 



T BUFFER 



210 



STATUS 
MEMORY 



TTY2 



R BUFFER 



T BUFFER 



STATUS 
MEMORY 



214 



USER MODE 
TASK 



HOST 
OPERATING 
SYSTEM; 



TTY3 



202 




R BUFFER 



T BUFFER 




CONTROL 
DEVICE 




NETWORK 
INTERFACE 



SERVER 



-20 



SUBSTITUTE SHEET {RULE 26) 



Hi 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US95/03183 



A. CLASSIFICATION OF SUBJECT MATTER 
IPC(6) :G06F 15/16 

US CL : 395/200 j | j 

According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 



U.S. 



395/200,800,500; 364/DIG.1.DIG.2; 



Documentation searched other than minimum documentation to the extent that such documents arc included in the fields searched 



Electronic! data base consulted during the international search (name of data base and, where practicable, search terms used) 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



| t j . i 

Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



A,P 



US, A, 5,265,239 (ARDOLINO) 23 NOVEMBER 1993, col. 1, 
line 60 et seq, col. 4, lines 1-38 



US, A, 4,972,368 (O'BRIEN ET AL.) 20 NOVEMBER 1990, 
col. 19, line 45 et seq. 

US, A, 4,547,880 (DE VITA ET AL.) 15 OCTOBER 1985 



US, A, 5,257,369 (SKEEN ET AL.) 26 OCTOBER 1993 



US, A, 5,355,453 (ROW ET AL.) 11 OCTOBER 1994 



1-14,16-17, 19- 
26 

3-5,13-14 
3-5 



1-14,16-17,19- 
26 

1-14,16,-17,19- 
26 

1-14,16-17, 19- 
26 



~] Further documents are listed in the continuation of Box C. |-[ | See patent family annex. 



A* 

E- 

L* 

cr 



Special catcg ones of chcd documents: ' 

document defining the general state of the art which b not considered 
_ lo be pan of particular relevance , 

earlier document published on or after the international filing date 



t which may throw doubt* on, priority claim<s) or which b 
cited to establish the publication date 'of another citation or other 
special reason (a* specified) j I r ' 

t ' t 
document referring lo an oral disclosure, use, cxhibilJon or other 



document published prior lo the international filing dale but later *K« n 

the priority date claimed ~ 



bier document published after the international filing dale or priority 
date sod not in conflict with the application but cited to understand the 
principle or theory underlying the invention 

f 

document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an tnvemive step 
when the document is taken alone 

! 

document of particular relevance; the' claimed inventtoo cannot be 
considered lo involve an inventive step when the document ia 
combined with one or more other such documcnu. such combination 
being obvious to a person skilled in the art 

document member of the same patent family 



Date of the actual completion of the international search 
19 APRIL 1995 



Date of mailing of the international search report 

15MAY1995 



Name and mailing address of the ISA/US 
Commissioner of Patents and Trademarks 
Box PCT 



^Authorized officer i 

u. r-r. . -i\ h 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US95/03183 



Box I Observations where certain claims were found unsearchable (Continuation of item 1 of first sheet) 



This international report has not been established in l e sp cct of certain claims under Article 17(2)(a) for the following reasons: 
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Claims Nos.: 

because they relate to parts of the international application that do not comply with the prescribed requirements to such 
an extent that no meaningful international search can be carried out, specifically: 
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because they are dependent claims and are not drafted in accordance with the second and third sentences of Rule 6.4(a). 
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3 . | | As only some of the required additional search fees were timely paid by the applicant, this international search report covers 
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4. | | No required additional search fees were timely paid by the applicant. Consequently, this international search report is 
restricted to the invention first mentioned in the claims; it is covered by claims Nos.: 
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1 . Basis of the report 

a. With regard to the language, the international search was carried out on the basis of the international application in the 
language in which it was filed, unless otherwise indicated under this item. 
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the international search was carried out on the basis of a translation of the international application furnished to this 
Authority (Rule 23.1(b)). 
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Certain claims were found unsearchable (See Box I). 
Unity of invention is lacking (see Box II). 



4. With regard to the title, 

' the text is approved as submitted by the applicant. 
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1 — 1 within one month from the date of mailing of this international search report, submit comments to this Authority. 

The figure of the drawings to be published with the abstract is Figure No. 63 

PH as suggested by the applicant. Q None of the figures. 

I I because the applicant failed to suggest a figure. 
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